Systems and methods for the collaborative design, construction, and maintenance of fluid processing plants

ABSTRACT

Systems and methods for the collaborative design, construction, and maintenance of fluid processing plants are provided. A collaborative commerce application may provide project management utilities, visualization utilities, dynamic pricing utilities, material procurement utilities, and certification utilities. These features may be integrated seamlessly into the collaborative commerce application. Communication among project team members in the design and construction of fluid processing plants may be made more efficient by providing automatic notifications via the collaborative commerce application. Version control may be used to ensure project team members are working with the latest designs and revisions. Access controls and other security features may be used to prevent confidential data from being disseminated unnecessarily.

This application claims the benefit of U.S. provisional application Nos.60/211,285, 60/211,254, 60/228,016, and 60/264,792, filed Jun. 13, 2000,Jun. 13, 2000, Aug. 24, 2000, and Jan. 29, 2001, respectively, which areall hereby incorporated by reference herein in their entireties.

BACKGROUND OF THE INVENTION

This invention relates to systems and methods for streamliningcollaborative processes, and more particularly, this invention relatesto a collaborative commerce application that may be used forcollaboratively designing, constructing, and maintaining fluidprocessing plants.

Engineering of, material procurement for, and construction of fluidprocessing plants has a long, complex design-build cycle. Furthermore,once construction is complete, material procurement for plantmaintenance, such as replacing a worn-out heat exchanger bundle orupgrading a processing vessel, is often a cumbersome, error-proneprocess.

Almost all facets of fluid processing plants, ranging from designing afluid processing plant, to constructing a fluid processing plant, tomaintaining a fluid processing plant involve a complex mesh ofprocedures, specialists, and materials. The complexity of engineeringinformation associated with fluid processing plants makes clear,accurate communication difficult. Because large numbers of people fromdifferent organizations are involved (e.g., the owner company customer,the engineering, procurement and construction (EPC) contractor, and themany vendors, fabricators and manufacturers), and because many of themmanipulate the data during the design, build, or fabrication phases,errors are very likely.

The pressure to deliver on schedule, and to eliminate as many errors aspossible, makes the bidding process slow and tentative. The engineeringmedia used, such as data sheets, specifications, and two-dimensionalcomputer aided design (CAD) drawings, are fundamentally clumsy and hardto distribute to remote locations. They must be reproduced and mailed—aprocess that consumes valuable time.

Version control presents another source of inefficiency. For example,much confusion typically arises when multiple engineering groups, forexample, at remote locations attempt to coordinate reviewing and editinga set of drawings. Often times, there is an inconsistency with regard tothe versions being worked on by the different engineering groups.

During the engineering of, material procurement for, and construction ofa fluid processing plant, a tremendous amount of equipment informationis developed. However, this information is often too difficult to accessto be of much benefit to the engineers and mechanics who later operateand maintain the plant.

Two trends in the industry have exacerbated these problems. One of thesetrends is globalization. For example, it is not unusual to doengineering in India and vessel fabrication in Korea for a fluidprocessing plant in France that is being built or upgraded for acustomer in Houston. The long distances between sites add tocommunication difficulty.

The second trend is an increasing use of three-dimensional CAD models.These models allow engineers to build a plant electronically beforebuilding it in the field in order to see connection points, testclearances, and check for human ergonomic factors early in the designprocess. As a result, the models help eliminate unwanted changes laterin the detailed engineering and construction process. Yet mistakes stillhappen, and they often do not become obvious until late in the cycle,when the cost of fixing them undercuts any efficiencies gained earlierin the process.

In addition, three-dimensional CAD modeling systems do little to makedesign review and procurement easier. It takes an expensive,sophisticated workstation to view a plant model. The models are so largethat e-mailing them from place to place is prohibitively time-consuming,even with high-speed Intranet or Internet access. If the model isshipped on a large capacity disk or if file transfer protocol (FTP) isused, the recipient can view it only with a tool that uses the sameproprietary software platform on which the three-dimensional model wascreated. Often, if the recipient does not have access to the proprietaryplatform, the recipient is required to make the investment necessary toobtain the platform.

Security is a source of problems with regard to complicated designmodels that go through several stages of revision. Once the entity thathas developed the model releases it, parties that do not necessarilyrequire access have access to the entire body of data.

It is therefore an object of the present invention to provide a way inwhich the design, construction, and maintenance of fluid processingplants may be made more efficient by removing major sources of error andallowing for easier collaboration.

SUMMARY OF THE INVENTION

This and other objects of the present invention are accomplished byproviding a collaborative commerce application for the design,construction, and maintenance of fluid processing plants.

The collaborative commerce application may be used to provide acollaborative environment in which project team members for a particularproject are able to communicate with each other using the latestinformation available. For example, version control may be made moreefficient by providing users of the collaborative commerce applicationwith notifications of any changes that may occur to designs, schedules,or any other suitable facets of a project. Task management utilities mayalso be provided to streamline the design, construction, and maintenanceprocesses.

Visualization features may be offered by the collaborative commerceapplication. For example, two or more remote project team members maydiscuss a design by each having a schematic of the design on theirrespective displays. The design may be editable by the project teammembers such that when changes are made, the other project team membersmay simultaneously see the changes on their displays. For those projectteam members that are configured to receive design changes, and who werenot present at the discussion, notifications provided by thecollaborative commerce application may provide information about anychanges made.

The collaborative commerce application may provide users (e.g., projectteam members, suppliers, manufacturers, or any other suitable users)with the ability to view graphical models of components used in fluidprocessing plants. The components may be components that are used in theconstruction of the fluid processing plants, in the maintenance of fluidprocessing plants, or both. Any suitable portion of the graphical modelmay be selected by the users. For example, sub-components may beselected. In response, the collaborative commerce application maydisplay information associated with the selected portion, such as a moredetailed schematic of the portion. In another suitable approach, thecollaborative commerce application may provide bills of materials forsub-components that are selected by users.

Material procurement may be accomplished using the collaborativecommerce application of the present invention. In one suitable approach,a requisition/approver/buyer cycle may be used, whereby a requisition ismade, an approver approves (or rejects) the requisition, and a buyer isresponsible for acquiring the material requested. For example, thisarrangement may be used in conjunction with a dynamic pricing feature.The dynamic pricing feature may provide users of the collaborativecommerce application with the ability to perform requests for quotes,reverse auctions, or any other suitable dynamic pricing events.

Material procurement may also be provided via, for example, searches.The collaborative commerce application may provide users with theability to perform searches based on, for example, metadata attributesof components. In one suitable approach, selecting a component from agraphical model may automatically allow for a search to be performedbased on the metadata attributes of the component selected. Searches mayalso be based on category (e.g., piping, valves, etc.), on part numbers(e.g., manufacturer part numbers, site part numbers, supplier partnumbers, etc.), on suppliers, on keywords, or on any other suitablecriteria.

Change order processing may also be provided by the collaborativecommerce application of the present invention. Notifications to suitableparties may be automatically generated when changes are made to orders,to dynamic pricing events, or to any other suitable aspect of materialprocurement.

The collaborative commerce application may provide certificationinformation about manufacturers of materials used in fluid processingplants. The information may include information related to thefabrication history of a facility, code stamps, employee trainingrecords, customer satisfaction records, inspectors' notes, videos andimages, quality assurance practices, and any other suitable information.In one suitable approach, a video walkthrough of a facility may beprovided. Any other suitable information may be requested by users ofthe collaborative commerce application.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects of the present invention will be apparentupon consideration of the following detailed description, taken inconjunction with the accompanying drawings, in which like referencecharacters refer to like parts throughout, and in which:

FIG. 1A is a schematic drawing of an illustrative collaborative fluidprocessing plant design, construction, and maintenance system inaccordance with one embodiment of the present invention;

FIG. 1B is a schematic drawing of the illustrative central site of FIG.1A in accordance with one embodiment of the present invention;

FIG. 2 is a block diagram of illustrative data that may be provided bythe collaborative commerce application in accordance with one embodimentof the present invention;

FIG. 3 is a flow chart of illustrative steps involved in thecollaborative features of the collaborative commerce application inaccordance with one embodiment of the present invention;

FIG. 4 is a block diagram of illustrative features that may be providedby the collaborative commerce application in accordance with oneembodiment of the present invention;

FIG. 5 shows an illustrative display screen in which a graphical modelmay be displayed by the collaborative commerce application in accordancewith one embodiment of the present invention;

FIG. 6 shows an illustrative display screen in which a graphical modelmay be displayed with information related to the graphical model inaccordance with one embodiment of the present invention;

FIG. 7 is a flow chart of illustrative steps involved in using a mark-upfeature in accordance with one embodiment of the present invention;

FIGS. 8A and 8B are flow charts of illustrative steps involved incataloging and providing users with access to component information inaccordance with one embodiment of the present invention;

FIG. 9 is a block diagram of an illustrative data flow in accordancewith one embodiment of the present invention;

FIG. 10 shows an illustrative display screen that provides searchfunctionality in accordance with one embodiment of the presentinvention;

FIGS. 11A and 11B show illustrative display screens that providecategory search functionality in accordance with one embodiment of thepresent invention;

FIG. 12A shows illustrative metadata for a component in accordance withone embodiment of the present invention;

FIG. 12B shows an illustrative display screen in which metadata may beused as search criteria in accordance with one embodiment of the presentinvention;

FIG. 13 is a flow chart of illustrative steps involved in using metadataattributes in searching for components in accordance with one embodimentof the present invention;

FIG. 14 shows an illustrative display screen that may be used to listsearch results in accordance with one embodiment of the presentinvention;

FIGS. 15–18 are flow charts of illustrative steps involved in using thecollaborative commerce application for dynamic pricing in accordancewith one embodiment of the present invention;

FIGS. 19A and 19B show illustrative display screens in which bidtabulation and bid analysis may be provided in accordance with oneembodiment of the present invention;

FIGS. 20A and 20B show illustrative display screens in for modifying andcancelling orders in accordance with one embodiment of the presentinvention;

FIG. 21 shows an illustrative display screen in which the status ofprior and pending orders may be accessed in accordance with oneembodiment of the present invention;

FIG. 22 shows an illustrative display screen in which inspection andcertification information may be accessed in accordance with oneembodiment of the present invention;

FIG. 23 is a flow chart of illustrative steps involved in thenotification of quality incidents in accordance with one embodiment ofthe present invention; and

FIG. 24 is a flow chart of illustrative steps involved in providingcertification information in accordance with one embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1A shows an illustrative collaborative fluid processing plantdesign, construction, and maintenance system 10 in accordance with thepresent invention. System 10 may include a central site 12. Central site12 may include any suitable hardware, software, or both. For example, asillustrated in FIG. 1B, central site 12 may include a web server 20, adatabase server 18, any suitable communications hardware (e.g.,satellite receivers/transmitters, modems, or any other suitablecommunications hardware, software, or both), or any combination of theseor any other suitable elements. Central site 12 may include one or moresites. For example, central site 12 may include equipment located atdifferent geographical locations.

Each client 16 may be any suitable collection of hardware, software,data, personnel, or any other suitable elements. In one suitableembodiment, each client 16 need not have the same elements as any otherclient 16. Alternatively, each client 16 may be required to have astandard collection of predefined elements. For example, client 16 maybe required to have, at a minimum, a personal computer and suitablecommunication hardware and software. This is merely an illustrativeclient representation. Any such suitable client 16 may be used.

Client 16 may communicate with central site 12 using communicationsnetwork 14. Communications network 14 may be any suitable communicationsnetwork such as, for example, a local area network (LAN), a wide areanetwork (WAN), an Intranet, the Internet, a telephone network, anysuitable wireless network, or any other suitable communications network.Suitable wireless networks may include time-division multiple access(TDMA) networks, code-division multiple access (CDMA) networks, or anyother suitable wireless networks.

In one suitable approach, a particular client 16 may communicate withcentral site 12 using one suitable form of communications network 14such as over the Internet, while another client 16 may communicate withcentral site 12 using another suitable communications network 14 such asa LAN. Any such suitable combination of networks may be used bydifferent clients 16.

Clients 16 may directly communicate with each other using communicationsnetwork 14. Alternatively, clients 16 may communicate with each othervia both communications network 14 and central site 12. Any suchsuitable arrangement may be used to allow clients 16 to communicate witheach other.

Client 16 and central site 12 may communicate over communicationsnetwork 14 using any suitable protocol or protocol stack. For example,client 16 and central site 12 may communicate via a transmission controlprotocol/Internet protocol (TCP/IP) environment and a hypertext transferprotocol (HTTP). Any suitable request-response type of protocol andsocket-based packet transport stack, or suitable peer-to-peercommunications approach may be used as desired.

Each client 16 may represent any suitable user of the collaborativeeffort in the design, production, or maintenance of fluid processingplants. For example, client 16 may represent an engineering office fromwhich design information or any other suitable information may becommunicated to central site 12. Client 16 may represent a constructionsite at which a fluid processing plant is being constructed. Client 16may represent a retailer of component parts that are used to maintainfluid processing plants. Client 16 may represent any such suitable userof the collaborative effort in the design, production, or maintenance offluid processing plants and is not limited to the preceding illustrativeexamples.

For purposes of clarity and brevity, the present invention is primarilydescribed herein using a client/server arrangement where communicationsnetwork 14 is the Internet. Communication between client 16 and centralsite 12 is primarily described using markup language, such as, forexample, hypertext markup language (HTML) or secure hypertext markuplanguage (HTTPS). A client 16 is primarily described as a personalcomputer that accesses central site via communications network 16 usinga world wide web browser. It should be understood that this is merely anillustrative embodiment and that the present invention is not limited tosuch an embodiment and may be modified in any suitable way.

Central site 12 is illustratively described as one or more servers onwhich a collaborative commerce application may be implemented. In analternative approach, one or more servers at central site 12 may accessa collaborative commerce application at another location via, forexample, communications network 14. The collaborative commerceapplication may be any suitable software, hardware, or both that may beused to provide the features of the present invention as describedherein. For example, the collaborative commerce application may includea web site, a database engine, an administrative interface, and anyother suitable components.

The present invention may be used to provide clients with any suitableinformation with regard to the design, construction, and maintenance offluid processing plants. FIG. 2 provides an illustrative high-level viewof how the collaborative commerce application may be used to providethis functionality of information distribution.

For example, any suitable information, such as three-dimensional images112, two-dimensional images 114, computer-aided design data 116,documentation 118, product data 119, audio data 120, video data 122,textual data 124, intelligent piping and instrumentation diagrams 126,bills of material 128, design data 130, component data 132, project data133, and any other suitable information may be parsed, processed, orboth by collaborative commerce application 134 for use by client 136.This model of information flow and distribution may be applied to anysuitable embodiment of the present invention.

FIG. 3 is a flow chart that shows an overview of an illustrative processfor communicating information between clients 16 and central site 12.For example, at step 140 any suitable data, information, or files suchas component designs, design modifications, pricing information,correspondences (e.g., e-mail, instant messages, or any other suitablecorrespondences) schedule information, data sheets, or any othersuitable data, information, or files may be communicated from a client16 to central site 12, via for example, communications network 14. Webserver 20 may be used for communicating with client 16. The content ofthe communication may be stored in database server 18.

At step 142, the collaborative commerce application of the presentinvention may provide a client 16 with the ability to access the contentof, for example, database server 18 at central site 12. In one suitableapproach, access to content may be limited based on, for example, theidentity of the particular client 16 attempting to access the content.

When a client 16 accesses content from central site 12, thecollaborative commerce application may allow client 16 to review,modify, and/or redline the accessed content, via, for example, aweb-browser and communication network 14 (step 144). Any such suitableapproach to the communication of content between clients 16 and centralsite 12 may be used.

In one suitable embodiment of the present invention, the collaborativecommerce application 30 of FIG. 4 may enable multiple parties that areinvolved in the design, fabrication, or maintenance of fluid processingplants to cooperatively work together. The parties involved on aparticular project are herein referred to as project team members.Project team members may include, for example, engineers, constructionpersonnel, investors, management personnel, maintenance personnel, orany other suitable parties. One or more project team members may berepresented as a client 16.

Suitable project management utilities 32 may be made available to themembers of a particular project team. Project management utilities 32may include task management utilities 34. Task management utilities 34may include calenders that may show, for example, projected completiondates for particular facets of the project, deadlines for particularmembers of the team to complete assigned tasks, and any other suitabledates. Other task management utilities 34 may include a checklist of alltasks that need to be completed, a project bulletin board that may beused to post notices for project team members to read, a white boardthat may be used by project team members for free-form collaboration, acomplete, time-stamped audit trail of all project activity, or any othersuitable task management utilities. If desired, a shared directory maybe made available to the project team members that may hold suitableinformation associated with the project team members such as, forexample, contact information, employer, project access, or any othersuitable information.

In one suitable approach, task management data may be exportable tosuitable hardware, software, or both from central site 12. For example,a project team member may export calendar data into his or her personaldigital assistant (PDA). If desired, any other suitable data fromcentral site 12 may be exportable to suitable hardware, software, orboth.

Project management utilities 32 may also include suitable communicationutilities 36. Communication utilities 36 may include, for example,instant messaging capabilities between project team members, emailnotifications to project team members, discussion groups within theproject team, or any other suitable communication utility. Emailnotifications may be automatically generated, for example, when changesare made to designs, or in response to any other suitable specifiedevent. Alternatively, email notifications may be sent from a member ofthe project team to other members of the project team. Any such suitableuse of email notification may be used. Discussion groups may be privateto just the project team. Alternatively, discussion groups may be in theform of public Usenet groups. Any such suitable use of discussion groupsmay be used. These are merely illustrative communication utilities thatmay be used by the present invention. It should be understood that anyother suitable communication utility may be used.

Collaborative commerce application 30 may also provide comprehensiveaccess controls 38 and workflow management capabilities 40 to its users.Some of these illustrative functionalities may include, for example,providing to a system administrator the ability to input and manageoverall domain access and permissions. Project-related permissions maybe managed by one or more designated users, such as, for example, aproject team leader. Domain workflow rules may be managed by a systemadministrator, while project-related workflow rules may be managed byone or more designated users, such as, for example, a project teamleader.

Access groups may be used, whereby all members of a particular accessgroup may be granted the same access privileges. If desired, the accessgroups of a particular project team may have a hierarchical structurewith certain access groups having more privileges than other accessgroups. In another suitable approach, access groups may be used todesignate particular project team members as having similarresponsibilities. Any such suitable use of access groups may beimplemented.

If desired, workflows and access controls from an existing project maybe cloned to a new project. For example, if a particular arrangement ofworkflows and access controls proved to be efficient in a particularproject, the same configuration may be used in a subsequent project.

Workflow management may be facilitated through the use of a graphicaluser interface for workflow configuration. Any suitable interface may beused. Other workflow management utilities 50 may include the ability toembed workflows within workflows (e.g., parallel or series workflows),the ability to provide branched workflows based on triggering events.Any suitable workflow management utilities may be used.

Project management utilities 32 of collaborative commerce application 30may allow specified project team members to electronically approvedesigns, materials, schedules, requisitions, or any other suitableelements of the design, fabrication, and maintenance of fluid processingplants. In order to facilitate the approval process, approval groups maybe used that identify respective approvers. Each approval group may haveone or more project team members associated with it. Approval requestersmay select an appropriate approver from a list of approval groups. Theapprover may then be notified that his or her approval is requested. Theapprover or approvers may be notified via any suitable notificationmethod, such as via email, instant messaging, paging, or any othersuitable notification method. In another approach, the approver may benotified manually, such as, for example, by the requester orallycommunicating the notification, via, for example, a telephone. Theapprover may be provided with any suitable information, such as, forexample, the identity of the original requester, the request creationdate, the request submission date, or any other suitable information.

Approvers that are delaying workflow may be reminded of pending requestsvia, for example, email, instant messaging, paging, or any othersuitable communication method. These reminders may be sent automaticallyby collaborative commerce application 30 based on the deadline datesspecified in, for example, the workflow, the approval request, or anyother suitable source of deadline information.

Once approvers examine the element which needs approval, the approversmay either approve the element or reject the element. In either case,the approver may be given the ability to annotate his or decision withone or more notes (e.g., in electronic form). In one suitable approach,anytime an element is rejected, the approver may be required to specifywhy it was rejected. Notes may be viewed by any suitable project teammembers.

In one suitable approach, collaborative commerce application 30 mayallow delegates to be designated for approval roles. For example, if aproject team member will not be available for a period of time, anotherproject team member may take on the approval role of the unavailableperson. Any suitable delegation feature may be used in instances ofproject team member unavailability.

Collaborative commerce application 30 may provide a visualizationfeature 42. Visualization feature 42 may provide collaborative commerceapplication 30 with capabilities for two-dimensional andthree-dimensional visualization and collaboration tools. These tools mayallow users to view, analyze, and annotate schematics and any othersuitable forms of data over, for example, communications network 14.Schematics may be in the form of two-dimensional images,three-dimensional images, 360° images, 180° images, or any othersuitable forms of images.

For example, FIG. 5 illustrates collaborative commerce applicationdisplay screen 81 that may be viewable by any suitable user, viacommunications network 14, at, for example, client 16. Image 89 may bedisplayed on display screen 81. Image 89 may be any suitable image. Forexample, image 89 may be an image of one or more parts that are to beused in the construction of a fluid processing plant. Image 89 may be inthe form of a two-dimensional image, three-dimensional image, 360°image, 180° image, or any other suitable type of image. Image 89 maycorrespond to one or more data files that may be stored at central site12 (in, for example, database server 18). For example, image 89 maycorrespond to any suitable computer-aided design file format (e.g., DWG,DXF, DWF, SLDDRW, DGN, Me10, MI, CMI, PRT, or any other suitablecomputer-aided design file format). Image 89 may correspond to anysuitable standards file format (e.g., CGM, CAL, CALS G4, MIL, ISO 9000compliant banners and watermarks, or any other suitable standards fileformat). Image 89 may correspond to common image formats (e.g., TIFF,JPEG, PCX, GIF, BMP, OOO, CIT, DG, DX, DIF, EDC, EDM, FTK, G3, G4, GP4,IGS, MOT, RLC, RLE, RNL, or any other suitable common image formats).Image 89 may correspond to file formats for three-dimensional imagery(e.g., DWG, MDB, DGN, PDMS, EXP, DRI, DRV, PRP, PRT, ASM, PAR, PSM, STL,WRL, or any other suitable three-dimensional image format). These aremerely illustrative image formats that may be supported by thecollaborative commerce application of the present invention. Any othersuitable formats may be supported in addition to these formats or inplace of any of these formats.

Image 89 may be printed by the collaborative commerce application usingany suitable plot file format (e.g., HPGL/2, 906, 907, or any othersuitable plot file format).

As illustrated, image 89 of display screen 81 is a three-dimensionalimage of a particular device that may be related to fluid processingplant construction or maintenance. Title and model information 66 mayalso be provided. The device represented by image 89 may be created fromone or more parts, such as parts 85 and 86. In one suitable embodimentof the present invention, users may select any parts of a device using,for example, cursor 72. In response to a user selection of a part, thecollaborative commerce application may provide further information onthe selected part.

For example, two dimensional image 87, that may, for example, showvarious views of the selected part (e.g., part 85) may be displayed indisplay screen 81. Data, such as data 80 may be provided using displayscreen 81. Data 80 may include any suitable information about theselected part (e.g., part 85). For example, data 80 may includeinformation related to manufacturers of the selected part, any suitablespecifications of the selected part, cost of the selected part, or anyother suitable data. It should be understood that display screen 81, asshown, is merely an illustrative display screen. Any other suitableinformation may be provided in addition to, or in place of, theinformation shown in display screen 81.

In one suitable approach, any suitable images, data, or both that isprovided via, for example, a display screen such as display screen 81may provide links (e.g., hyperlinks) to additional information relatedto the corresponding image or data. For example, in display screen 81,users may obtain additional information about x corporation by selectinglink 82, using, for example, cursor 72, or by using any other suitableselection technique.

In one suitable embodiment of the present invention, the collaborativecommerce application may enable users to select any device, part, or anyother suitable object, from, for example, a schematic, a data sheet, orfrom any other suitable source. Upon selection, the collaborativecommerce application may provide additional information related to theselected object via. FIG. 6 shows an illustrative display screen 90 thatmay be displayed in response to a request for additional informationrelated to a particular object. Additional information may be providedin any suitable form. For example, additional information may be aspecification or data sheet, a bill of materials, contact information,any other suitable information, or any suitable combination thereof.

Specification sheet 92 may include any suitable information related to aparticular component. Image 98 may be displayed with specification sheet92 in display screen 90. Image 98 may be any suitable image of thecomponent for which the specification sheet provides information. Forexample, image 98 may be a two-dimensional image, a three-dimensionalimage, or any other suitable type of image.

Display screen 90 is merely illustrative. Any other suitable arrangementmay be used. In another suitable approach, selection of a componentresult in the collaborative commerce application providing informationin place of or in addition to the content illustrated in FIG. 6. Forexample, a bill or material may be provided that may be used to list thesubassembly components of a selected component.

Visualization tools may also be used with regard to the collaborationfeatures of the collaborative commerce application of the presentinvention. For example, users may access image data or create imagedata, via, for example, communications network 14. Users may thenannotate, edit, or create images related to particular projects withwhich the users are associated. For example, as shown in FIG. 5 thecollaborative commerce application may provide editing tools 106.Editing tools 106 may include any suitable editing tools. For example,editing tools 106 may include tools for creating various shapes, forchoosing colors, for using imaging effects, for inserting text, forchanging views, or for performing any other suitable editing functions.In one suitable approach, editing tools may be as robust as desired,even mimicking application suites such as AutoCAD or any other suitableapplications that provide graphics editing tools. In terms of hardware,any suitable devices may be used to input any edits. For example,traditional mice, digital pens, tablets, optical mice, or any othersuitable device may be used to input edits.

In one suitable approach, particular users (i.e., project team members)may be given editing capabilities that may depend, for example, on auser's access level or on any other suitable classification.

FIG. 5 shows a user using editing tools 106 to add notations 102 toimage 89. The user may be involved in the design of this particularobject and may have the access that would allow him or her to make suchedits. Edits may include edits to the actual design. Edits may alsoinclude redlining. Redlining, as used herein, includes annotating,marking-up, or otherwise showing what changes are to be made or showingwhat changes were made. Redlining may be used for graphical objects(e.g., image 89) or for textual data (e.g., specifications,requisitions, or any other suitable textual data).

In one suitable approach, display screen 81 may be a display screen thatmay be used in a teleconference. For example, in a design meeting withdesigners and engineers, where some members of the project team are indifferent locations, the collaborative commerce application may be usedto allow the members to visualize, in real-time, changes that are beingproposed. More particularly, by using existing designs and data that arebeing stored at central site 12, clients may access the latest versionsof the designs and may change them (e.g., temporarily for the purpose ofthe meeting, or permanently if, for example, the members agree to thechanges). As one client changes the latest version, all other clientsmay view the changes being made, via, for example, display screen 81.

FIG. 7 is a flow chart that illustrates the above-mentioned process. Atstep 108, the changes that were made by one of the clients is receivedat central site 12. At step 110, these changes may be sent to all otherclients that are taking part in the teleconference. Changes may beuploaded from each client to the central site on periodic intervals.Alternatively, the collaborative commerce application may communicatechanges from clients to central site 12 by determining if a change hasbeen made to the data on the client side. Once data is received atcentral site 12, the data may be relayed to all clients 16 that areparticipating in the teleconference. These are merely illustrative waysin which edit data may communicated among clients 16 via system 10. Anyother suitable method may be used.

In another suitable embodiment of the present invention, thecollaborative commerce application may provide functionality for productand material procurement (as illustrated by box 46 of FIG. 4). In suchan embodiment, in addition to designers, engineers, executives,strategists, and any other suitable entity associated with the design,construction, and maintenance of fluid processing plants, clients 16 mayalso include component source entities such as component suppliers,component manufacturers, component distributers, component resellers,component retailers, and any other suitable component source entities.

Component source entities may provide central site 12 with information,including, data sheets, pricing information, availability information,and any other suitable information regarding components that may be usedin the design, construction, and maintenance of fluid processing plants.The collaborative commerce application may, in turn, allow project teammembers to access the information provided by the component sourceentities.

FIG. 8A is a flow chart of an illustrative process that may be used toallow component source entities to provide central site 12 withcomponent information. At step 150, the collaborative commerceapplication may give the component source entities the ability to submitcomponent information to central site 12, via, for example,communication network 14. When the component is submitted, then at step152 the component information may be stored in a database, such asdatabase 18, and made available to prospective buyers, via, for example,communications network 14 and the collaborative commerce application.

FIG. 8B is an illustrative process that may be used to allow projectteam members that may be prospective buyers of components to accesscomponent information (and purchase suitable components). At step 154,the component information that was stored in a database, such asdatabase 18, may be cataloged in a comprehensive product catalog by, forexample, the collaborative commerce application. This may be done using,for example, any suitable database arrangement, such as a relationaldatabase with appropriate key indices. Any other suitable approach forcataloging components may be used. At step 156, prospective buyers maybe given the ability to access the cataloged component information via,for example, communications network 14 and the collaborative commerceapplication. When the prospective buyers find the components for whichthey are searching, they may be offered the opportunity to purchase thecomponents.

In one suitable approach, the collaborative commerce application mayprovide users with the ability to access product information (i.e., forcomponents, etc.) by accessing databases maintained by suppliers. Forexample, a supplier of particular components may maintain a database ofinformation for those components. The collaborative commerce applicationmay seamlessly provide information from the supplier's database to usersof the collaborative commerce application via the collaborativecommerce's interface.

Clients 16 may be given the ability to access the cataloged componentinformation through the use of any suitable method. In one suitableapproach, artificial intelligence functionality may be used by thecollaborative commerce application to determine the components that aredesired, required, or both for a particular project. For example, eachproject may have associated with it one or more profiles. There may beone or more profiles associated with each project team member. There maybe one or more profiles associated with the project. If desired, theremay be both of these types of profiles and any other suitable type ofprofile. The profiles may contain information regarding preferences forparticular component sources, preferences for particular components,budget allocations, and any other suitable information. Profiles forindividual project team members may contain personal information such asname, address, telephone numbers, access level (e.g., for orderingcomponents), and any other suitable information. The collaborativecommerce application may determine the type of components that aparticular project may need at any particular time based, for example,on any or all of the profiles associated with the project and with theproject team members. The basis of the collaborative commerceapplication's component suggestions may also include the current statusof the project.

FIG. 9 illustrates this flow of information. Project data 158 andproject profiles 160 may be used by collaborative commerce application164 in conjunction with component database 162. Using these resources,collaborative commerce application 164 may determine suitable componentinformation 166 to provide to appropriate project team members 168.

In another suitable embodiment of the present invention, thecollaborative commerce application may enable project team members tomanually find components, manufacturers, distributers, etc. For example,the collaborative commerce application may provide search functionality,whereby clients 16 may be given the ability to use any suitable searchtechniques to find, research, and procure any components associated withthe design, construction, and maintenance of fluid processing plants. Inone suitable approach, clients may provide search terms (e.g., by havingpersonnel enter the terms in a search field in an interface) that areused as searching criteria in parsing the component database.

FIG. 10 shows an illustrative display screen 165 that may be displayedby the collaborative commerce application. Display screen 165 mayprovide suitable search functionality. For example, field 167 may beused to perform a search based on corporate or site specificationnumber, corporate or site part number, or both. Field 169 may be used toperform a search based on an any suitable unrestricted keywords. Fields175 and 173 may be used to perform a search based on supplier partnumber and manufacturer part number, respectively. These part numbersmay be cross-referenced by the collaborative commerce application withcorporate and site part numbers. Drop down menu 171 may be used to allowusers of the collaborative commerce application to limit searches tospecific suppliers, for example. FIG. 10 is merely illustrative. Anyother suitable arrangement may be used.

The collaborative commerce application may also provide category searchfunctionality. In one suitable embodiment, customized, detailedinterfaces may be displayed by the collaborative commerce applicationbased on, for example, a high-level category selection. FIGS. 11A and11B illustrate a category search for piping valve gates.

In another suitable approach, metadata may be used as search criteria.For example, when a project team member views, for example, a design ofa particular portion of a fluid processing plant, the project teammember may select individual parts (as previously described). Each partmay have metadata associated with the part. For example, FIG. 12A showsan illustrative part 170 with illustrative metadata 172. Metadata 172may include any suitable attributes of part 170. Suitable attributes mayinclude part specification, manufacturer or manufacturers, supplier orsuppliers, part numbers, or any other suitable attributes.

Project team members may be given the ability to perform a search basedon the attributes supplied by the metadata. FIG. 12B shows anillustrative search menu 174 that the collaborative commerce applicationmay provide based on the part selected. Search menu 174 may displaymetadata attributes 186.

FIG. 13 is a flow chart of the illustrative steps just described. When aclient selects a part from, for example, a two-dimensional drawing or athree-dimensional model, then the collaborative commerce application maydisplay metadata attributes that correspond to the select part at step190. This is merely an illustrative way in which the metadata attributesmay be accessed. Any other suitable way may be used, such as the userselecting a part from a list of parts. The user may be given the abilityto perform a search for the selected part, and if the user chooses to doso, the collaborative commerce application may dynamically create asearch menu using the metadata attributes. The user may be given theability to select a search type and the search criteria. The results ofthe search may be displayed at step 194.

FIG. 14 shows an illustrative search result display screen 196. Anysuitable information may be displayed on display screen 196. Forexample, as illustrated, each component or part listed in display screen196 may have particular information displayed in various columns. Forexample, a supplier column 198 may provide supplier information, aproduct name column 202 may provide product name information, a catalognumber column 204 may provide catalog number information, an amountcolumn 206 may provide weight or any other suitable amount information,a price column may provide pricing information, and a quantity column210 may allow the project team member to specify the quantity desired.These are merely illustrative fields that may be used to displayparticular information about parts and components. Any other suitablefields may be used in addition to or in place of the those illustrated.

Referring back to FIG. 12B, the collaborative commerce application mayprovide a dynamic pricing feature 184. Dynamic pricing (box 44 of FIG.4) may include a request for quote (RFQ), a reverse auction, atraditional type of auction, or any other suitable type of dynamicpricing process.

The collaborative commerce application may provide any suitablefunctionality for RFQs, reverse auctions, or any other similar type ofdynamic pricing process (i.e., with the buyer asking for bids). Forexample, the collaborative commerce application may provide a “wizard”that may be used to streamline the dynamic pricing process. The wizardmay be coupled with a graphic user interface that requests particularinformation from a requisitioner, an approver, a buyer, and a bidder.

Dynamic pricing may begin with a requisitioner preparing a requisitionthat is to be communicated to an approver or directly to a buyer. FIG.15 shows a flow chart of illustrative steps involved in therequisitioning phase. At step 212, the collaborative commerceapplication may give the requisitioner the ability to provideinformation regarding the part or component being sought. Informationmay include a general description of the part or component, the type orcategory of equipment being sought (e.g., heat exchanger, vessel, orANSI pump), part or component attributes, a title, or any other suitableinformation. The wizard may use drop down menus for some of theinformation that may be provided by the requisitioner. For example, apart or component category may be chosen from a drop down menu. In onesuitable approach, attributes may be chosen in the manner thatattributes 186 are chosen in FIG. 12B. These are merely illustrativetypes of information that the requisitioner may be given the ability toprovide. The collaborative commerce application may provide therequisitioner with the ability to provide any other suitableinformation.

At step 214, the requisitioner may be given the ability to attach filesto dynamic pricing requisition. For example, the requisitioner mayattach files from client 16 to the requisition. In another suitableapproach, the requisitioner may provide a links to files stored atcentral site 12. In yet another suitable approach, the requisition mayprovide hyperlinks to, for example, World Wide Web pages. Any suchsuitable attachments may be made to the dynamic pricing requisition.

At step 216, the information and attachments may be communicated to oneor more appropriate project team members. In one suitable approach, theproject profile may specify that all dynamic pricing requisitions besent directly to a buyer. In this case, the information and attachmentmay be directly communicated to a designated buyer. In another suitableapproach, the project profile may specify that an approver must reviewand approve dynamic pricing requisitions. In this case, the informationand attachment may be communicated to an approver.

FIG. 16 is a flow chart of illustrative steps involved in an approvalphase of a dynamic pricing requisition. At step 218, information andattachments provided by the requisitioner may be communicated to adesignated approver by the collaborative commerce application. At step220, the collaborative commerce application may provide the approverwith the ability to view the information and the attachments. Theapprover may also be provided with the ability to add notes or notations(e.g., further part specifications, budget information, or any othersuitable notes or notations). The approver may also be provided with theability to electronically approve or reject the requisition (e.g., via acheckbox, radio buttons, or via any other suitable interface element).At step 222, the information provided by the requisitioner, theattachments provided by the requisitioner, and any additional notes ornotations added by the approver may be forwarded to one or moreappropriate project team members (e.g., buyer and requisitioner). In thecase that a requisition was not approved, the buyer need not get anycommunication.

In one suitable embodiment, the approver may be given the ability tospecify a list of one or more back-up buyers. For example, in the eventthat the specified buyer for a particular project or for a particularfacet of a project (e.g., as defined by the project profile) isunavailable, then the approver may designate one or more back-up buyers.

FIG. 17 is a flow chart of illustrative steps involved in the buyingphase of the dynamic pricing requisition process. At step 224, theinformation, notes and notations, and attachments provided by therequisitioner and approver (assuming there was an approval phase) may becommunicated to a designated buyer. At step 226, the collaborativecommerce application may provide the buyer with the ability to view theinformation, notes and notations, and attachments. The buyer may also begiven the ability to add information, add attachments, select an eventtype (e.g., RFQ, reverse auction, multistage negotiation, sealed bid,English auction, Dutch auction, Japanese auction, or any other suitabletype of dynamic pricing event), add an expiration date, specify time andtime zone, specify quantity desired, identify specific required bidderresponses (e.g., cash terms, availability, etc.), select bidders from alist of potential bidders, or perform any other suitable action.

At step 228, suitable information and attachments may be communicated toprospective bidders. Bidders may be selected as in step 226 (i.e.,selected by the buyer). In another suitable approach, bidders may beautomatically selected by the collaborative commerce application,whereby the category or type of the part or component being sought (asprovided by the requisitioner) may be used as a basis for determiningwhich bidders are selected. In one suitable approach, the collaborativecommerce application may take into account project profiles indetermining which bidders to choose. Any such suitable approach fordetermining which bidders to send the information to may be used.

FIG. 18 is a flow chart of illustrative steps involved in the biddingphase of the dynamic pricing process. At step 230, relevant information,including attachments, and any other suitable material may becommunicated to bidders. At step 232 the bidders may be provided withthe ability to electronically respond to the request. The response mayinclude attachments.

Throughout the dynamic pricing process, the involved parties may receivenotifications whenever one of their communication is received by therecipient. For example, when each bidder receives a request, the buyermay receive a notification (e.g., via e-mail) that particular bidderreceived the request.

In one suitable approach, a bidder's response may not be visible toother bidders. In another suitable approach, only some parts of abidder's response may be visible to other bidders. Any such privacyfeature may be implemented. If desired, the privacy feature may be basedon user preferences (e.g., as defined in project profiles).

In one suitable embodiment, when the buyer receives bidders' responses,any required bidder responses that the buyer specified may beautomatically tabulated by the collaborative commerce application forcomparison and evaluation. If desired, all fields of the responses maybe tabulated for comparison and evaluation—not just required responses.

The collaborative commerce application of the present invention may alsoprovide functionality for traditional auctions. For example, suppliersmay place any suitable parts or components on auction to solicit bidsfrom any suitable parties (e.g., other suppliers, builders, etc.). Awizard, as previously described, may be used by the supplier to create anew auction and to interact with bidders. Files and links may likewisebe attached to a traditional auction as was described for a dynamicpricing event. Any other suitable features for a traditional auction maybe used in accordance with the present invention.

Dynamic pricing techniques may be beneficial for parts and componentsthat are not widely available. For parts and components that arecommonly available, the collaborative commerce application may providesuitable procurement features that may enable buyers to access updatedprice information, availability information, supplier information, andany other suitable information for these parts and components. Thecollaborative commerce application may also provide buyers with theability to place orders electronically.

The collaborative commerce application may provide to appropriateproject team members the ability to view, in an organized andcustomizable way, the bids and any other suitable data for a dynamicpricing event. FIGS. 19A and 19B show an illustrative display screen 233that may be displayed by the collaborative commerce application toprovide a tabulation of bids. Any suitable information may be displayedin the tabulation of bids. For example, prices, quantities,availability, fees, shipping dates, or any other suitable informationmay be displayed in the bid tabulation of display screen 233. The bidtabulation may be used to compare the terms being offered by differentbidders.

In one suitable approach, information may be organized by thecollaborative commerce application in the bid tabulation usingoptimization tools 234, 235, and 236. For example, optimization tool 234may organize bids based on lowest price and delivery date. Optimizationtool 235 may organize bids based on lowest prices alone. Optimizationtool 236 may organize bids based on alternate lowest price and deliverydates taking into account alternate bids. Customization tool 237 may beprovided by the collaborative commerce application to allow users todefine custom bid organization schemes.

The collaborative commerce application may analyze bid information andindicate a recommended bid based on, for example, how well a particularbid corresponds to project profiles. Display screen 233 shows bid 239 asbeing indicated to be a recommended bid.

The collaborative commerce application may allow users to make anysuitable annotations to bids in the bid tabulation. For example, acheckbox 238 may be provided that may allow users to indicate whether aparticular bid is technically acceptable.

The collaborative commerce application may provide bidders with theability to submit alternate bids (e.g., having a different price for adifferent quantity). The collaborative commerce application may alsoprovide buyers with the ability to view alternate bids. Display screen233 (FIG. 19B) shows alternate bid 311 for a particular bidder. Thealternate bid may provide the same type of information as the originalbid, but may have different parameters.

The bid tabulation may also provide an approval workflow 310 that maydetail the chain of approvals for a particular requisition.

In one suitable embodiment of the present application, change orderprocessing features may be implemented in the collaborative commerceapplication. Change order processing may include the ability to havebuyers, bidders, or any other suitable entities change information thatwas previously submitted. For example, orders may be changed orcancelled.

When a user wishes to change an order, such as a request for quote,requisition, or any other suitable type of order, the collaborativecommerce application may provide the user with the ability to initiateany desired changes, from, for example, an order status display screen.The ability to change an order may be provided from any other suitablelocation in the interface of the collaborative commerce application.

When activated, the order change feature of the collaborative commerceapplication may provide an editable copy of the order. The editable copyof the order may include additional fields that may be used to specifychanges being made. FIG. 20A shows an illustrative display screen 240that may be displayed by the collaborative commerce application fororder cancellations and modifications. Item 241 is shown to becancelled. The cancellation may be indicated by the redlining. Moreparticularly, a strikethrough appearance may be generated by thecollaborative commerce application over the content of fieldscorresponding to the cancelled order. This is merely an illustrative wayof indicating an order cancellation. Any other suitable indication maybe used.

Redlining may be used to indicate order modification. That is, anysuitable indicators may be used to identify previous information (e.g.,field contents) and to identify new information.

In another suitable approach, modification may be made by having thecollaborative commerce application provide users with the ability tochange information without the use of redlining. For example, as shownin display screen 240, the order for item 242 is being modified. In theillustrated case, the collaborative commerce application may provideeditable fields, such as field 244, that the user may use to makechanges to the order for item 242.

When modifications are submitted, the collaborative commerce applicationmay display a display screen such as display screen 244 of FIG. 20B.Display screen 244 may display an audit trail 245 that may be indicateany modifications and cancellations made to prior or pending orders.

Display screen 240 and 244 are merely illustrative. Any other suitablearrangement may be used and any other suitable information may bedisplayed. For example, revision numbers may be displayed for ordersthat have been modified or cancelled. Any such information may bedisplayed. Any additional fields may be provided by the collaborativecommerce application. For example, additional user-editable fields maybe provided for approving changes, for providing special instructions,or for any other suitable purpose related to order modification orcancellation.

In one suitable approach, a cancellation need not result in an orderbeing deleted from the system. In this situation, the cancelled ordermay be archived as a revised order. This may allow the order to bereactivated at a later date if the cancellation was a mistake or wasdone to postpone the order. Although a cancellation may be made, thecollaborative commerce application may process payment for orders thatare partially complete at the time of cancellation (e.g., if thesupplier has almost completed fabrication of a vessel, a cancellationfee is imminent).

Changing and cancelling orders may be done by authorized project teammembers for a particular project. For example, in one suitable approach,the collaborative commerce application may only allow the requisitionerof a particular order to change or cancel the order. In another suitableapproach, approvers of the order being changed or cancelled may be giventhe authorization to change or cancel the order. Any such suitabledesignation of authority may be given. If desired, such designation maybe determined by appropriate project team members and specified in theproject profiles.

In one suitable embodiment of the collaborative commerce application ofthe present invention, when an order is changed or cancelled,appropriate project team members, and appropriate sellers (i.e., whowere supposed to supply the order) may be notified of the changes orcancellation by the collaborative commerce application. In one suitableapproach, the information communicated to different project team membersand sellers may be based on the identity of the recipient. For example,the sellers may receive information regarding the changes to thespecification of the product being ordered. The project team leaders mayreceive information on all facets of the order change, including, forexample, any additional notes, reasons for changes, etc. Thenotification may take any suitable form as previously described herein.

The collaborative commerce application may provide project team memberswith the ability to review the history of the orders. For example, aproject team member may be allowed to access the status of all pendingand prior orders related to a particular project.

FIG. 21 shows an illustrative order status display screen 250 that maybe provided by the collaborative commerce application. Display screen250 may display a listing 258 of all pending orders for a particularproject. Each listing may provide any suitable information about thecorresponding order. For example, as illustrated in display screen 250,an order number information 251, number of revisions information 252,and order title 254 may be provided. Any other suitable information maybe provided about pending or prior orders.

In one suitable approach, the collaborative commerce application mayprovide users with the ability to change a particular order or toperform any other suitable activity on a particular order. Activitiesmay be displayed in a drop-down menu such as drop-down menu 256. Anysuitable activities may be performed on one or more particular orders.Selecting a particular order may cause the collaborative commerceapplication to display additional information about the selected order.For example, selecting a particular order may cause the collaborativecommerce application to display a history of the selected order,including any revisions made. Any such suitable information about apending or prior order may be displayed by the collaborative commerceapplication.

In one suitable approach, the collaborative commerce application mayprovide to sellers a display screen that may be similar to displayscreen 250. Sellers may be given the ability to view orders that are tobe filled, orders that have been filled, or both. Additional informationabout a particular order may be provided to sellers upon selection ofthe order.

In one suitable embodiment of the collaborative commerce application ofthe present invention, inspection and certification may be providedelectronically (box 52 of FIG. 4). For example, the certificationinformation for a fluid processing plant may be electronically filed andaccessible via the collaborative commerce application. Certificationinformation may include, for example, review of fabrication history forfive years (or any other suitable period of time), review of code stampsand employee training records, review of the level of customersatisfaction for the manufacturers of equipment, parts, and componentsused in the fluid processing plant, the quality assurance practices ofthe manufacturers of equipment, parts, and components used in the fluidprocessing plant, certified inspectors' notes made during a walkthroughof the facility, and any other suitable information that a user mayrequest.

FIG. 22 shows an illustrative display screen 270 that the collaborativecommerce application may provide to project team members or any othersuitable entity. Display screen 270 may be used to allow users to accessinspection and certification information for a particular manufacturer.For example, in the illustrated case, the collaborative commerceapplication provides access to inspection and quality assurances 274.These may include quality standards, quality analyses, source inspectionreports, field test procedures, field inspection reports, safetyanalysis, fabrication history, code stamps, employee training records,customer satisfaction records, inspectors' notes, videos and images, orany other suitable information. In one suitable approach, thecollaborative commerce application may also provide users with theability to request other particular information. This is merely anillustrative arrangement and array of choices. Any other suitableinformation may be provided using any other suitable arrangement.

In one suitable embodiment, the collaborative commerce application mayprovide users with the ability to view video of a facility walkthrough,video of actual fabrication processes being performed, video ofinspections being performed, or any other suitable video. Other forms ofcontent may be used in addition to or in place of video. For example,any suitable images or video clips may be used. Streaming video may beused. Videos with or without sound may be used.

Display screen 270 shows video 272. Video 272 may be any suitable videorelated to the inspection and certification of a particularmanufacturer, including, for example, facility walkthroughs,manufacturing processes, or any other suitable events. Video 272 is notlimited to prerecorded video. For example, video 272 may include a livevideo feed, a slide show of images, or any other suitable graphics-basedcontent.

The collaborative commerce application may therefore be used by projectteams to certify particular manufacturers for use in one or moreparticular projects. That is, particular manufacturers may be designatedas certified for particular project based on information that may beprovided by the collaborative commerce application. Project team membersmay designate certified manufacturers via the collaborative commerceapplication. The certified manufacturers may be placed in projectprofiles for use with features described herein (e.g., dynamic pricingrequests).

The collaborative commerce application may provide notifications (via,for example, e-mail, instant messaging, or any other suitable form ofcommunication) to suitable project team members whenever a manufacturerthat is certified with associated projects suffers a serious qualityincident at its facility. A notification may also be communicated tosuitable project team members if a certified manufacturer's processesare no longer in control based on, for example, statistical processcontrol charts. Notifications may also be communicated in the event thattraining records or code stamps are no longer valid for a certifiedmanufacturer's facility. These are merely illustrative examples oftriggers that may cause the collaborative commerce application tocommunicate notifications to suitable project team members. Any othersuitable triggers may cause the communication of notifications tosuitable project team members.

FIG. 23 is a flow chart of illustrative steps involved in notifyingusers of the collaborative commerce application in the event of aquality incident at a manufacturer's facility. When, at step 300, aquality incident (e.g., as described above) occurs at a facility, thenat step 302 the collaborative commerce application may notifyappropriate users of the occurrence.

The collaborative commerce application may provide users with theability to perform a search of ongoing projects for inspection andcertification purposes. That is, by observing the progress (or lackthereof) being made by a particular manufacturer in ongoing projects, adecision for whether that manufacturer should be certified for aparticular project may be made. Security features may be implemented,whereby the information provided to users with regard to other projectsmay be based on, for example, code or password protection.

Assuming security is satisfied, users may be provided with any suitablecertification and inspection information. For example, final pass androute pass x-rays may be provided for welding projects. In addition,mill certifications, final inspection written reports, fabricationupdate video, or any other information may be provided by thecollaborative commerce application.

All of the certification and inspection information for a particularmanufacturer may be stored at central site 12 (FIG. 1A). The informationmay be accessed by any suitable entities. For example, potentialcustomers of the manufacturer may be given the ability to access theinformation. In another suitable approach, certification and inspectioninformation for a particular manufacturer may be stored at a databasethat is not located at central site 12. The collaborative commerceapplication may be used to access the other database via, for example,communications network 14. In the case of critical or large files, suchas x-rays, communication of the files may be made through the use ofwireless satellite linkup, or through the use of any other suitablebandwidth-on-demand technique.

FIG. 24 is a flow chart of illustrative steps involved in providinginformation related to certification. At step 304, information relatedto certification may be compiled and stored at central site 12, using,for example, the collaborative commerce application.

Thus, Internet-based collaborative commerce for the design,construction, and maintenance of fluid processing plants systems isprovided. One skilled in the art will realize that the present inventioncan be practiced by other than the described embodiments, which arepresented for purposes of illustration and not of limitation, and thatthe present invention is limited only by the claims which follow.

1. A method for using a collaborative commerce application for searchingfor a particular component for use in a fluid processing plant,comprising: associating the component with particular metadataattributes; displaying a graphical model of the component; allowing auser to select the graphical model; performing a search of a componentdatabase using the metadata attributes associated with the selectedcomponent to obtain respective values associated with the metadataattributes; and dynamically creating a search menu using the metadataattributes and the respective values obtained from the componentdatabase.
 2. The method of claim 1 further comprising providing the userwith the ability to search based on a basis selected from a groupconsisting of category, site part number, supplier part number,manufacturer part number, supplier, keyword, and any combinationthereof.
 3. The method of claim 1 further comprising providing the userwith the ability to choose which metadata attributes to use as searchcriteria from the search menu.
 4. The method of claim 1 furthercomprising displaying search results using fields based on metadataattributes.
 5. A system for using a collaborative commerce applicationfor searching for a particular component for use in a fluid processingplant, the system configured to: associate the component with particularmetadata attributes; display a graphical model of the component; allow auser to select the graphical model; perform a search of a componentdatabase using the metadata attributes associated with the selectedcomponent to obtain respective values associated with the metadataattributes; and dynamically create a search menu using the metadataattributes and the respective values obtained from the componentdatabase.
 6. The system of claim 5 further configured to provide theuser with the ability to search based on a basis selected from a groupconsisting of category, site part number, supplier part number,manufacturer part number, supplier, keyword, and any combinationthereof.
 7. The system of claim 5 further configured to provide the userwith the ability to choose which metadata attributes to use as searchcriteria from the search menu.
 8. The system of claim 5 furtherconfigured to display search results using fields based on metadataattributes.